Description of problem: Currently to enable ssl on a volume using gdeploy the following flow has been followed. 1) creates a volume 2) set volume options 3) starts the volume 4) Generate private key 5) Generate self-signed-certificates 6) Copy the signed certificate to localhost 7) Create CA file on servers 8) Enable management encryption 9) stop the volume 10) Set volume options for SSL 11) Restart glusterd 12) start the volume With the above flow if there is single volume in the cluster all works well. If there are multiple volumes in the cluster, same flow is repeated thrice and user will be able to mount only the volume which is created at the last. The other two volumes will be using old certificates and user will not be able to mount them. Currently in HC setup we have three volumes which needs to be created and once gdeploy finishes creating volumes, user will not be able to mount the other volumes and because of this installation does not proceed and it fails. It would be good to have a different section for enabling ssl so that the process is not repeated and setting volume options can be done in the volume creation itself. Version-Release number of selected component (if applicable): gdeploy-2.0.1-8.el7rhgs.noarch How reproducible: Always Steps to Reproduce: 1. Use gdeploy to enable ssl on more than one volume in the cluster. 2. 3. Actual results: User will be able to mount only the last volume and volumes created before this he would not be able to mount. Expected results: User should be able to mount all the volumes and isolate enabling ssl and volume creation sections in gdeploy. Additional info:
put blocker '?' because when volumes are created using gdeploy with ssl_enabled, mounting of volume does not work and due to his hc installation fails.
Also the workflow goes like this when the volume requires encryption: 1. Create volume 2. Set volume options ( if provided as part of [volume] gdeploy ansible module ) 3. Start the volume 4. If encryption is required on the volume, ssl options ( server.ssl=on & client.ssl=on) are set on the volume 5. Stop & Start the volume In the above workflow the volume goes through start->stop->start states. The corrected workflow could be: 1. Create volume 2. Set volume options ( if provided as part of [volume] gdeploy ansible module ) 3. If encryption is required on the volume, SSL volume options ( server.ssl=on & client.ssl=on) are set on the volume 4. Start the volume With the corrected workflow, there is only one volume start and reduces the gdeploy configuration time.
(In reply to SATHEESARAN from comment #3) > Also the workflow goes like this when the volume requires encryption: > > 1. Create volume > 2. Set volume options ( if provided as part of [volume] gdeploy ansible > module ) > 3. Start the volume > 4. If encryption is required on the volume, ssl options ( server.ssl=on & > client.ssl=on) are set on the volume > 5. Stop & Start the volume > > In the above workflow the volume goes through start->stop->start states. > > The corrected workflow could be: > 1. Create volume > 2. Set volume options ( if provided as part of [volume] gdeploy ansible > module ) > 3. If encryption is required on the volume, SSL volume options ( > server.ssl=on & client.ssl=on) are set on the volume > 4. Start the volume > > With the corrected workflow, there is only one volume start and reduces the > gdeploy configuration time. sas, the volume stop-start is added because we support ssl setup on existing volumes as well. And we try to stop first to ensure we don't do anything on running volumes.
Currently gdeploy follows the 3 step process when enabled per volume 1. Creation of SSL files ( glusterfs.key, glusterfs.pem, glusterfs.ca ) 2. Enabling SSL with glusterd 3. Enabling SSL on that gluster volume The above 3 steps are done together when the volume section has 'enable_ssl=yes' and 'ssl_clients=host1,host2' So, the above 3 steps should not be done together as it may contradict the some case. Take for instance, when expanding the cluster, user may just require to generate SSL cert files on the new host and turn on SSL for glusterd but not on the volume, as the volume would have already enabled SSL In other case, he may have the SSL certs creating by his own ( say there is a CA available ), in that case the user may just want to turn on SSL on glusterd and volumes, but not to generate SSL cert files once again. Gdeploy should consider all these cases and provide the flexibility to handle above mentioned cases
Since this functionality will be moved to gluster-ansible in future, this bug is flagged for closure. If there is a requirement to fix in 3.x please update the bug.
But is there any need to have this bug kept open here?
If there were any requirements to fix this in 3.x updates; I was expecting a comment here. Now that I don't see anyone commenting from past two weeks, we can close this.